Module windows created entirely with DXL?

Tony_Goodman - Wed Jun 17 02:49:38 EDT 2009
DOORS is mostly DXL.
The database explorer window is implemented entirely using DXL.
All dialogs are DXL.
All menus, toolbars, pop-ups etc are DXL. Some menu options are implemented using "standard items", these can be called from DXL but how they are implemented is unknown.
One exception to this is the menu that pops-up after drag-and-drop: this is not implemented in DXL (well it might be internally?) and cannot be modified.

The module window is not DXL (except for the menus, toolbars and pop-ups). I would guess that the original intention was to use DXL, but it did not provide the necessary functionality required.

If you have DOORS 9.0, notice the icons for module windows have changed. Icons on explorer and dialogs (implemented in DXL) remain the same which is a picture of doors with red telelogic triangle.

djakad - Wed Jun 17 12:16:28 EDT 2009
The reason I ask... I often find myself going down the path of trying to develop an alternate user interface to DOORS using DXL (i.e., a large, complex dialog box). But, each time I go down that path, I throw up my hands in frustration with the complexity of the resulting DXL code, or the limitations of DXL, or my lack of patience, or a combination of all those.

There are some things that drive me nuts about DOORS. For one, I find it cumbersome to have a separate window for every open module. If you have a lot of modules open, your Windows session can get quite cluttered. I often imagine a "tabbed browser", where each module is a tab in a tab strip (and you open the modules in hidden mode, so as to have just one visible dialog box). And the first tab can mimick the main DOORS window, with a database and module browser. I have made a few attempts to create this, and I get pretty far along, but I struggle with the best way to "display" each module in the dialog box.

One method is to use a listView, where each object is displayed in a row of the listView, and columns are added in the listView for attributes, etc. One challenge with this method is, typically your object text is quite long, and does not display well in the single-text-line of each row in the listView. You also have no way of displaying OLEs (but, I am not sure I care about that). I have attempted this method with some moderate success. You can get around the single-line limitation by including a "detail pane" using richText boxes, which show you the full text of the selected row.

Another method is to use a series of (or rows of) richText boxes. You can then display each object text in a richText box. You can have multi-line richText boxes. Although, richText boxes are not re-sizeable... once they are realized on the dialog box, they are a fixed size. I have created this kind of "module view" in a dialog box with some mediocre success. I even managed to include a zero-width, full-height canvas with scrollbar, where when you scroll the scroll bar, the richText boxes update, giving the appearance of scrolling through the module.

Another method is to use a canvas. Although, I find this even more complex to implement. Trying to draw all the object text on to the canvas and get it all placed right, and provide the appearance of scrolling, inPlace editing, all the mouse-click regions you need, etc. It is a nightmare to code. Since the canvas is just an image, you must store all the real object text in a Skip list or something similar, behind the scenes. There is a lot of memory management and pointer management needed. At least with a listView or richText boxes, you can actually use the DBEs to store the info, as well as display it.

If you look at the "complex canvas" commands, such as hasHeader, inPlace editors, etc., it appears that either 1.) the module windows are created using these canvas commands, or 2.) these complex canvas commands were developed with the intention of re-coding the module windows using these DXL commands. My guess is, the current module windows have some C or C++ behind them. And, at some point, Telelogic attempted to re-create the module windows using DXL, but found it to be too complicated. I reach this conclusion because, while many of the "complex canvas" commands seem to imitate features in the module windows, there are some features of the module windows that are impossible to re-create using the available DXL commands. For example, there is no way to change the font size or font style in the inPlace canvas text editor. However, in a module window, this is possible, as you can see and change the font size/style of object headers, etc.

Again, maybe it's not worth the struggle. But it keeps me entertained. And I can't stop that recurring dream of a better DOORS interface.

djakad - Wed Jun 17 12:16:28 EDT 2009
The reason I ask... I often find myself going down the path of trying to develop an alternate user interface to DOORS using DXL (i.e., a large, complex dialog box). But, each time I go down that path, I throw up my hands in frustration with the complexity of the resulting DXL code, or the limitations of DXL, or my lack of patience, or a combination of all those.

There are some things that drive me nuts about DOORS. For one, I find it cumbersome to have a separate window for every open module. If you have a lot of modules open, your Windows session can get quite cluttered. I often imagine a "tabbed browser", where each module is a tab in a tab strip (and you open the modules in hidden mode, so as to have just one visible dialog box). And the first tab can mimick the main DOORS window, with a database and module browser. I have made a few attempts to create this, and I get pretty far along, but I struggle with the best way to "display" each module in the dialog box.

One method is to use a listView, where each object is displayed in a row of the listView, and columns are added in the listView for attributes, etc. One challenge with this method is, typically your object text is quite long, and does not display well in the single-text-line of each row in the listView. You also have no way of displaying OLEs (but, I am not sure I care about that). I have attempted this method with some moderate success. You can get around the single-line limitation by including a "detail pane" using richText boxes, which show you the full text of the selected row.

Another method is to use a series of (or rows of) richText boxes. You can then display each object text in a richText box. You can have multi-line richText boxes. Although, richText boxes are not re-sizeable... once they are realized on the dialog box, they are a fixed size. I have created this kind of "module view" in a dialog box with some mediocre success. I even managed to include a zero-width, full-height canvas with scrollbar, where when you scroll the scroll bar, the richText boxes update, giving the appearance of scrolling through the module.

Another method is to use a canvas. Although, I find this even more complex to implement. Trying to draw all the object text on to the canvas and get it all placed right, and provide the appearance of scrolling, inPlace editing, all the mouse-click regions you need, etc. It is a nightmare to code. Since the canvas is just an image, you must store all the real object text in a Skip list or something similar, behind the scenes. There is a lot of memory management and pointer management needed. At least with a listView or richText boxes, you can actually use the DBEs to store the info, as well as display it.

If you look at the "complex canvas" commands, such as hasHeader, inPlace editors, etc., it appears that either 1.) the module windows are created using these canvas commands, or 2.) these complex canvas commands were developed with the intention of re-coding the module windows using these DXL commands. My guess is, the current module windows have some C or C++ behind them. And, at some point, Telelogic attempted to re-create the module windows using DXL, but found it to be too complicated. I reach this conclusion because, while many of the "complex canvas" commands seem to imitate features in the module windows, there are some features of the module windows that are impossible to re-create using the available DXL commands. For example, there is no way to change the font size or font style in the inPlace canvas text editor. However, in a module window, this is possible, as you can see and change the font size/style of object headers, etc.

Again, maybe it's not worth the struggle. But it keeps me entertained. And I can't stop that recurring dream of a better DOORS interface.

djakad - Wed Jun 17 12:16:28 EDT 2009
The reason I ask... I often find myself going down the path of trying to develop an alternate user interface to DOORS using DXL (i.e., a large, complex dialog box). But, each time I go down that path, I throw up my hands in frustration with the complexity of the resulting DXL code, or the limitations of DXL, or my lack of patience, or a combination of all those.

There are some things that drive me nuts about DOORS. For one, I find it cumbersome to have a separate window for every open module. If you have a lot of modules open, your Windows session can get quite cluttered. I often imagine a "tabbed browser", where each module is a tab in a tab strip (and you open the modules in hidden mode, so as to have just one visible dialog box). And the first tab can mimick the main DOORS window, with a database and module browser. I have made a few attempts to create this, and I get pretty far along, but I struggle with the best way to "display" each module in the dialog box.

One method is to use a listView, where each object is displayed in a row of the listView, and columns are added in the listView for attributes, etc. One challenge with this method is, typically your object text is quite long, and does not display well in the single-text-line of each row in the listView. You also have no way of displaying OLEs (but, I am not sure I care about that). I have attempted this method with some moderate success. You can get around the single-line limitation by including a "detail pane" using richText boxes, which show you the full text of the selected row.

Another method is to use a series of (or rows of) richText boxes. You can then display each object text in a richText box. You can have multi-line richText boxes. Although, richText boxes are not re-sizeable... once they are realized on the dialog box, they are a fixed size. I have created this kind of "module view" in a dialog box with some mediocre success. I even managed to include a zero-width, full-height canvas with scrollbar, where when you scroll the scroll bar, the richText boxes update, giving the appearance of scrolling through the module.

Another method is to use a canvas. Although, I find this even more complex to implement. Trying to draw all the object text on to the canvas and get it all placed right, and provide the appearance of scrolling, inPlace editing, all the mouse-click regions you need, etc. It is a nightmare to code. Since the canvas is just an image, you must store all the real object text in a Skip list or something similar, behind the scenes. There is a lot of memory management and pointer management needed. At least with a listView or richText boxes, you can actually use the DBEs to store the info, as well as display it.

If you look at the "complex canvas" commands, such as hasHeader, inPlace editors, etc., it appears that either 1.) the module windows are created using these canvas commands, or 2.) these complex canvas commands were developed with the intention of re-coding the module windows using these DXL commands. My guess is, the current module windows have some C or C++ behind them. And, at some point, Telelogic attempted to re-create the module windows using DXL, but found it to be too complicated. I reach this conclusion because, while many of the "complex canvas" commands seem to imitate features in the module windows, there are some features of the module windows that are impossible to re-create using the available DXL commands. For example, there is no way to change the font size or font style in the inPlace canvas text editor. However, in a module window, this is possible, as you can see and change the font size/style of object headers, etc.

Again, maybe it's not worth the struggle. But it keeps me entertained. And I can't stop that recurring dream of a better DOORS interface.

dpechacek - Tue Jun 23 13:33:34 EDT 2009
Trust me, I share your pain. But as far as I can tell, it is impossible to implement the Module window in DXL.

However part of what you describe is now offered in DOORS Web Access. The only thing it can't do is add new objects, delete objects, and create links. And that is coming. I'm not advocating Web Access, just saying.

In 2011 though I think you'll sort of get what you want since then DOORS will be fully implemented in the Jazz architecture. Which means provided you can get past the authentication part to gain access to the data, you'll be able to access it through the Jazz APIs. Then you'll be able to write your own interface to the data.

AAI Services, Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com